Object oriented component and framework architecture for signal processing

ABSTRACT

A signal intelligence system comprising a plurality of software components that are programmable to provide a signal intelligence function. The signal intelligence system includes a processor system having a plurality of interconnected processor devices and a plurality of processor managers that are connected to the processor devices and are configured to control software components associated with the processor devices. Further, the signal intelligence system has a framework manager that is configured to interact with the plurality of processor managers to control the processor devices and effectuate the signal intelligence function

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.12/386,136, filed Apr. 14, 2009, which is a divisional of U.S.application Ser. No. 11/063,951 filed Feb. 23, 2005, now U.S. Pat. No.7,559,056, which is a continuation of U.S. application Ser. No.10/233,338, filed Aug. 30, 2002, now abandoned.

FIELD

This invention relates to distributed signal processing systems and moreparticularly to the use of object oriented techniques to provide areconfigurable signal processor.

BACKGROUND

Historically, signal processing has been performed using a combinationof special purpose hardware and software designed for the specificdigital signal processor environment used in a particular application.At times when no real-time operating system was available, theprogrammer had to be concerned with every detail of memory management,communications and scheduling. Even when real-time operating systemssuch as VxWorks have been available, the signal processing programmertypically needed to be concerned about the specific memory,input/output, and communications architecture of the processor used.

As a result, signal-processing software was difficult to reuse. In thepast, signal processing has placed strong demands on processingthroughput, often approaching the entire processing capacity of thecomputer or computers used. To maximize performance for the capabilityof a given computer or set of computers, the design and implementationof the signal processing software was closely tied to the particularhardware architecture and was also closely tied to the particularoperating system and related libraries previously developed. Hence,reuse was difficult due to the fact that this signal processing softwarewas closely tied to the particular hardware architecture and operatingsystem used. This signal processing software required optimization for aparticular application and was designed for specific functionalityrather than to comply with an overarching architecture for reuse.Presently, due to the complex nature of signal processing tasksinvolved, specialized equipment and software is developed for each andevery one of the signal processing requirements. What results is amultiplicity of processor types, a multiplicity of operating systems,and a multiplicity of hardware components, none of which are reusablefrom one application the other.

With the advent of more capable general-purpose processors and operatingsystems, whether real-time or not, it became possible to consider a moregeneral and reusable approach to signal processing.

Many vendors now provide computer modules in the form of cards with oneor more processors, memory, and input/output with high performance andintegral communications capabilities. These communications are oftenprovided by dedicated hardware on the computer modules and are usuallydesigned to be scalable so that as modules are added to the system, thecommunication bandwidth is also increased. However, generally thesecomputer modules are dedicated to one specific type of operating systemand related libraries. The task of reusing signal processingapplications when converting from one computer module to another,particularly between different vendors, remains a difficult, timeconsuming, and expensive task.

There is therefore a need to find means to exploit modern hardware andsoftware engineering approaches to define an architecture for signalprocessing that would allow for software reuse and rapid systemdevelopment owing to that reuse. It is also important that thearchitecture developed not be tied to any particular processor type orhardware so that one can quickly take advantage of processorimprovements, or at least not fall victim to the disappearance of aparticular processor type or hardware from the commercial marketplace.

For instance, in an airborne communication, command, and controlpayload, there are various functions that such a system must perform.These include a communications relay function, signals intelligenceprocessing function, acoustic signal exploitation function, andidentification of friend-or-foe function. In the past, each of thesefunctions required a separate set of processors and specializedhardware. The payload system integrator was required to incorporate inthe equipment bay a number of highly independent sub-systems ofspecialized equipment, because common equipment could not be reused orreconfigured to provide the required functionality. In the equipmentperforming the signal intelligence processing, one needs to have areceiver interface, a signal energy detection system, signal recognitioncapability, radio direction finding capability and a countermeasuresystem that can include jamming. Each of these functions was priorlyperformed by separate processors and specialized hardware. It isinteresting to observe that the a communications relay function,acoustic signal exploitation function and identification offriend-or-foe function require similar, if not identical capabilities.

In the past, in order to accomplish each of the above-named functionswhere one has very limited payload restrictions, the payload equipmentand software was selected prior to flight in which only one capabilitywas permitted per mission. It is desired to be able to reuse variousprocessing capabilities and hardware capabilities for multiple tasks,permitting multiple capabilities per mission.

Thus, one of the major problems with writing software for signalprocessing in the past has been the inability to reuse software thatpreviously has been developed for specific applications and particularhardware suites.

Previously, distributed signal processing applications were so demandingthat they were written to be tightly coupled to a particular computerplatform, a particular operating system, and the communicationsinfrastructure that was being used. Reuse for different applications wasvirtually impossible. Further, when the computer platform changed or thecommunication infrastructure changed, that software had to bere-written.

SUMMARY OF THE INVENTION

In order to solve the problem of having signal processing performedusing a combination of special purpose hardware and software designedfor the specific digital signal processor environment used in aparticular application, in the subject invention, an object-orientedsystem or architecture is used to provide an overarching architecturefor reuse. With the advent of more capable general purpose processorsand operating systems, whether real-time or not, the subject systemmakes it possible to consider a more general and reusable approach ofsignal processing.

As a result, in the subject invention, object-orientedcomponent/framework architecture is used with several key attributes.

The first is that the framework provides many underlying infrastructurecapabilities needed by signal processing systems such as various meansof communication, code downloading, processing control, error loggingand other functions.

Secondly, the framework is layered so that the details of the interfaceto the hardware, processors and communications are isolated in specificlayers. The signal processing application software in the upper layer isisolated from the operating system, communication infrastructure, andprocessor hardware. This localizes any changes in the system requiredfor easy porting to new processors to the lowest layers, and as aresult, investment in the signal processing application is preserved.

Thirdly, signal processing techniques and algorithms are encapsulated incomponents that perform their individual functions without explicitdependency or direct interaction with any other components in thesystem. This makes the designed component highly modular and morereusable. Each component must meet the required interfaces to theframework to ensure proper operation of the overall system.

Fourthly, all components take advantage of the object-oriented approachto inherit much of their capabilities from component base classes thatprovide commonly needed capabilities to fit into the framework andoverall system architecture. This approach facilitates rapid developmentfor new components from direct reuse of much common software code.Further, these component base classes provide the interface between thecomponents and the interface from the components to the framework,relieving the burden of complying with these interfaces from thesoftware component developer.

Fifthly, the framework and component approach embodies a standardizedsignal or streaming-data processing architecture to implement manydifferent signal or streaming-data processing applications. In order toperform a specific processing application, reusable and reconfigurablesoftware components are deployed and execute on one or moreinterconnected computers. Each of these processors is coupled to a datacommunication fabric that provides interconnection of messages from eachprocessor. In typical embodiments these are buses, switched circuits, orcombinations of both. Each computer has a Processor Manager, anexecutable program part of the framework which orchestrates frameworkinfrastructure services for that particular computer and the componentsthat execute there. The entire signal processing system is under thegovernance of a Framework Manager, another executable part of theframework that deploys, connects and runs the components in accordancewith a Plan. The Plan defines the signal processing task or tasks byspecifying the components to be used, the computer or computers toexecute each component, the interconnection of the inputs and outputs ofeach of the components, and the parameters that control the behavior ofeach of the components.

The subject system thus meets the need to greatly increase the abilityto reuse software from one signal processing application to the next. Inaddition it makes the process of porting to the next generationcomputing hardware a much faster and easier process. By contrast, in thepast most applications had to be redesigned and recoded to operate oneach new hardware computation platform. It became sadly apparent that bythe time one could complete that effort, this computation platform wouldno longer be a state-of-the-art, and a time-to-market window might havebeen missed. What was therefore needed was a leapfrog technology to beable to access state-of-the-art components and to arrange them in anobject-oriented framework architecture to perform the signal processing.

The subject system defines a component-framework architecture to be usedfor signal and streaming-data processing. Except for a specific hardwareinterface layer, it is hardware independent, and uses a modernobject-oriented approach so that the software can be reused. The subjectarchitecture also promotes portability and the ability to take advantageof rapidly evolving, highly capable, general-purpose commercialoff-the-shelf processors.

The following U.S. patents detail object-oriented programming frameworksand their use in applications other than signal processing: U.S. Pat.Nos. 6,424,991; 6,195,791; and, 6,308,314

In summary, a reconfigurable distributed signal processing system usesan object-oriented component-framework architecture in which theprocessing system architecture permits large-scale software reuse. Thisis accomplished by the use of a reusable, layered framework and a numberof reusable, reconfigurable software components that are both highlymodular and hardware independent. The components communicate over a datafabric using open published APIs and one or more data communicationsmechanisms. Interchangeable software components are used that performthe signal processing. Interchangeability is assured by each componentmeeting a required interface; the component inherits the requiredinterface elements from component base classes. This use of inheritanceto assure interface compliance also reduces the programming workrequired for developing a component. Most importantly, theinterchangeable components are reconfigurable into various systems atruntime, as defined by a Plan. A Plan is a schematic of theconfiguration of the various components to be used to solve a particularsignal processing problem which includes the list of components, whatcomputer each component is to execute on, how the components areinterconnected, and the initial parameter values of the components. Thesystem functionality and capability can be reconfigured at runtime basedon a Plan read by a software element of the framework, the FrameworkManager.

Moreover, the source code for the components is platform independentsince all the software which interacts with the operating system and thecomputer hardware is isolated in separate software layers with welldefined interfaces based on well-recognized industry standards. Sincethe approach allows the use of multiple independent hardware andoperating system interface layers at the same time, the system is ableto use heterogeneous commercial off-the-shelf hardware to minimizeequipment costs and lower non-recurring engineering costs as well. Thesystem uses object-oriented software development and programming in awell-defined architecture to enable large-scale reuse as a way to reducetime to market and to ensure program success.

The required interfaces for each interchangeable component include thecomponent-framework interface, input ports, output ports, parameters,plots, statistics, and error handling. The components do not communicatedirectly with specific other components but only through theirinterfaces with the framework. The components themselves inherit fromthe component base classes characteristics to ensure interfacecompatibility and to dramatically reduce programming work required whendeveloping the component. The list of classes from which the componentinherits includes a component controller, a transform, input and outputports, a plot and/or statistics ports.

It will be appreciated that the subject system is platform independentin that the component uses the Operating System Application ProgrammingInterface, or OSAPI, not native calls, meaning that the operating systeminterfaces are not used directly. Since each operating potentially has adifferent interface, instead one uses a specialized OSAPI layer thattranslates from a standardized interface to the specialized interface ofeach native operating system.

In operation, a Plan is devised and is passed to a Framework Managerwhich deploys the components to the various processors through aProcessor Manager and connects the output ports to the input ports foreach of the components, sets the component parameters, sets theparameters on the output ports, starts the particular components andmonitors the health of the system.

The subject system is therefore configurable using independent,reusable, interchangeable components executing on one or more computernodes interconnected by a data fabric or bus structure to which iscoupled the Framework Manager and various processors, with the Planbeing inputted to the Framework Manager for the overall reconfigurationand control of the signal processing system. What one has achieved isthus a reconfigurable signal processing system that can be reconfiguredat runtime.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features of the subject invention will be betterunderstood in connection with the Detailed Description in conjunctionwith the Drawings, of which:

FIG. 1 is a block diagram of the subject system illustrating theconnection of a framework manger, components, and process manager to acommunications fabric;

FIG. 2 is a block diagram showing the system of FIG. 1, showing theinterconnections of the parts logically rather than all going throughthe communications fabric;

FIG. 3 is a diagrammatic illustration of a Unified Modeling Language,UML, class diagram for the structure of a component;

FIG. 4 is a UML class diagram for an example simple component calledTMP;

FIG. 5 is a UML class diagram showing associations for the simple TMPcomponent; and,

FIG. 6 is a diagrammatic illustration of the layered architecture of oneembodiment of the subject invention.

DETAILED DESCRIPTION Basic Architecture

In order to provide for the subject framework architecture for signalprocessing, a system 10 includes a number of components 12 and 13 whichare connected through a communication fabric 14 to each other and to aFramework Manager program 16, which is provided with a Plan 18 fordefining the system. Each of the components is coupled to a respectiveProcessor Manager program 20 and 22, with the components executing on anumber of respective computers 24 and 26, each computer having itsassociated Processor Manager 20 and 22.

The communication fabric permits communication between the components ofthe Framework Manager and associated Processor Managers as well ascomputers so that system can be reconfigured based on Plan 18 read byFramework Manager 16.

It will be noted that each of the components have standardizedinterfaces, namely an one or more input ports 34, one or more outputports 36, parameters port 38, and a plot port/statistics port 40. Theseinterfaces are managed by objects: an input port object manages theinput port interface, an output port object manages the output portinterface, a parameters object manages the parameters, and anotherparameters object manages the statistics interface. Further, a plotobject manages the plots interface. Components also include a transformobject 42, the purpose of which is to instantiate the particularfunction that the component is to perform.

Each component has access to the native operating system only byinterfacing through the Operating System Application ProgrammingInterface, OSAPI, 42 so that regardless of the particular computer oroperating system used, the component operating system interactions aretransformed to that of the particular computer and operating system.

In operation, the system described in FIGS. 1 and 2 operates as follows:For a particular signal processing application a system designer orapplication engineer first constructs a Plan 18. A Plan is apreformatted file representing a schematic of the configuration of thevarious components to be used to solve a particular signal processingproblem. It defines components, their interconnections andinterconnection communication methods, and initial parameters to controlcomponent activity. Components may be assigned to particular computers,useful when certain computers have input/output interfaces withparticular hardware such as signal digitizers required by the specificcomponent. Optionally, the Framework Manager will assign components tocomputers at run time. The plan is prepared separately based on taskingfor the system.

On system boot-up the Framework Manager is loaded and started. TheFramework Manager starts a process thread that monitors requests fromOutside Application Programs 50 which seek to task or control thesystem. Once any outside application sends a message to a pre-definedport, the Framework Manager accepts it and establishes an identity andreference for that application.

As each computer in the system boots up and comes on-line, the ProcessorManager program is loaded and started on each participating computer inthe system. Each Processor Manager broadcasts a UDP packet to registerwith the Framework Manager indicating that it is present and ready toaccept components. This message is received by the Framework Manager,which acknowledges each processor manager. As the Framework Managerestablishes communications with each Processor Manager it develops alist of all the computers having a Processor Manager. These computerswith Processor Managers are the available processing assets.

The Outside Application requests that the Framework Manager load thepre-constructed plan for operation. Typically more than one plan can bein operation at the same time in the same system. In fact multiple planscan share components provided the identities of those are the same inboth plans.

The Framework Manager analyzes the Plan and deploys the particularcomponents onto computers 24 and 26 as dictated by the Plan and theavailable computers. This is accomplished by the Framework Managerpassing the name or names of the component or components for thatcomputer to Processor Manager 20 or 22 on that computer. It will beappreciated that one or more of the many processors in the system mayhave failed and therefore their Processor Manager isn'table to registerwith the Framework Manager so the plan can be configured around thefailure. Each Processor Manager then downloads the requested componentsfor its particular computer. The components then register with theProcessor Manager that in turn tells the Framework Manager that thecomponent is loaded. The Framework Manager maintains a list ofcomponents and their locations. From time to time, for example everysecond, the Processor Manager sends a message to each component deployedon its computer to determine whether each component is still functioningnormally. Failed components are unregistered and the Processor Managernotifies the Framework Manager that in turn logs the condition andnotifies the outside application.

The Processor Manager starts the execution of component 12 and thisoccurs for each of the components identified in the Plan.

The Framework Manager also analyzes the Plan and identifies theparameters for the particular components. The Framework Managercommunicates via parameter interface 38 in setting the parameters forthe particular component to the correct default values as identified inPlan 18. Again, this occurs for each component in the Plan.

Next, the Framework Manager analyzes the Plan and identifies theconnection or connections between the output ports 36, outPorts, of thecomponents and the input ports 34, inPorts of the components. Thisconnection-based communication mechanism is peculiar to signalprocessing where streams of data are passed between the components toperform the aggregate system processing required. The Framework Managerlooks in its processor list and obtains the identity and reference forthe source and destination components. The connection is establishedbetween the output port and the input port by the Framework Managercommunicating to the output port 36 a list of destinations which are theidentities of the input ports on each of the components that are to beconnected. To do this the Framework Manager obtains the input portreference from the destination component and the output port referencefrom the source component. The port types are compared against the Planto ensure validity. If they are valid, the Framework Manager tells thesource component to connect its output port to the input port of thedestination component. The output port then sends a message to the inputport instructing it to accept data or events from the particular outputport. This again is repeated for each connection specified in the Plan.Using this method it is possible for an output to be received bymultiple input ports and for a single input port to listen for data orevents from more than one output port. Note that these connections areestablished at runtime. These connections may also be removed andreestablished from one component to other components, hence, making thesystem reconfigurable at runtime.

Various methods for communication are available within the system andrepresented by the communication fabric 14. Physical connections,including busses, point to point connections, switched data fabrics, andmultiple access networks are abstracted by logical layers in the systemso that several logical connection types are available for communicationbetween components. In one embodiment, the default specifies remoteobject method calls via a real time object request broker, ORB. The ORBcomplies with the industry standard Common Object Request BrokerArchitecture, CORBA and is implemented by an off-the-shelf product. Thisselection is in keeping with the underlying object-oriented architectureof the system, but can be changed. Other communication means includesockets, which are supported by the target operating systems, and thenative communications protocols of the switched fabric interconnectsbeing used. One example is GM over Myrinet. The Plan defines thecommunication type and that type is sent to the ports when thecommunications are established as defined above.

Finally, when all the deployment and connections are completed, theFramework Manager starts each of the components using the start methodon the component interface of each of the components 12. Upon invocationof the start method, the components commence processing any signals orevents arriving at the component input port or ports and may outputsignals or events from output ports.

If the parameters of a component need to be changed, Outside ApplicationProgram 50 first needs to determine the available parameters. Via theORB it calls the component to request definition of its parameters. Thecomponent returns the available parameters. The outside application canthen call the component to request current parameter values, change theparameter values, or register to be notified when parameters are changedby some other means, ie. another outside application. Then whenparameters are modified the component notifies all registeredapplications of the change. When it is finished the outside applicationcalls the component to unregister for notifications.

Components

The component, itself an executable program, has required interfaces asshown in FIG. 2, namely an input port 34, an output port 36, parameters38, plots and statistics 40. These interfaces are managed by objects inone embodiment as shown in the standard Unified Modeling Language, UML,class diagram of FIG. 3. The specific application component 51 has aninput port object 52 which manages the input port interface; an outputport object 54 which manages the output port interface; a parameterSetobject 56 which manages the parameters; a Statistics ParameterSet object58 which is another ParameterSet that manages the statistics interface;and a ComponentPlot object 60 which manages the plots interface.Components also include a Transform object 62, the purpose of which isto implement the particular function that the component is to perform.The statistics and parameters are part of the Component object 64 whichprovides control for the overall component.

Each of the components is similar in that it performs a cohesiveprocessing step and meets the same interface. In addition to requiringthat each component meet this defined interface, the classes that defineobjects that manage the interfaces, input port class, output port class,parameters class, and plot class, all inherit their underlyingcapabilities from the corresponding base classes. The base classesprovide a guaranteed interface outside the component and provide defaultuseful functionality. This reduces the amount of specialization aparticular software developer is required to create in order to have afully functioning component.

The transform is an object that performs the required signal processingwork. These are generally different for each component providing thespecialized transformation of data that is done as part of the signalprocessing. There can be one or many of the transforms in eachcomponent.

However, the basic form of each these objects which together form acomponent, input port, output port, component, transform, parameters,statistics, plots, is the same and they are guaranteed to be compatiblewith the interface because they inherit from the base classes. The inputport base class provides an interface to receive data or events. Thecomponent base class provides an interface to the framework and theProcessor Manager for identification of the basic control of transformsand the ports. The transform base class provides a simple interface tobe used by the component developer. The plotting base class providesengineering and plotting interface used typically for debugging andanalyzing problems in the components. Using the plotting interface,arrays or vectors of numbers in the memory of the component may berendered as signals graphically. The need for this visualizationcapability is unique to signal processing. The output port, again,provides the means of outputting signals from the component using commonmechanisms.

Example

Each component developed to be interoperable, is developed by extendingthe base classes for the input port, output port, component, transform,and plots, and using the parameters class. Referring to FIG. 4, a simpleexample component, the TMP component is presented. Each of the baseclasses are extended for the particular specialized additionalcapability required for the particular component.

Note: for purposes of illustration, and as one example of a practicalembodiment of the subject invention, the C++ language representation formethods is used. Other embodiments of this invention may use otherobject-oriented programming languages, such as JAVA. The specific methodnames identified herein are only as an example of one embodiment of thisinvention.

With respect to the input port, the base class for the input port is theInPort class. InPort is used by the component writer and is extended forthe particular component. In the case of the TMP component, thetmpDataInput and TmpEventInput classes each extend the inPort baseclass. The purpose of the input port is to accept signal data or eventsinto the component. The inPort class has a number of methods that thecomponent writer uses and extends. Signal data or events are decomposedinto packets for transmittal across the data communication fabricbetween output ports and input ports. The input port accepts three typesof data packets that are essential for signal processing. These consistof headers and a payload. The headers provide auxiliary descriptivedata, so-called side-channel data representing where, when and how thedata was collected, and possibly processed. The first two types of data,shorts and floats are two types of signal data where the values in thisdata represent sampled signal data. Real or complex data may be passed.The third type of data is data which represents events, typicallyprocessing results which are representative of single action activitiesin time, which serve as triggers for subsequent signal processing.

Component Inputs

The inPort base class has methods for initialization and shutdown. Theconstructor InPort( ) and destructor .about.InPort( ) are extended bythe component developer to become the particular inPort that is used forthe particular component. In the example, these extended or specializedmethods are TmpDataInput( ) and .about.TmpDataInput( ), for theTmpDataInput class, and TmpEventInput( ) and .about.TmpEventInput( ) forthe TmpEventInput class. The constructor is used to create all therequired data structures for a particular object of class inPort.Likewise the destructor is used to delete them. Methods are provided formessage registration permitting the component to identify if it wants toreceive incoming signal or event packets, which are registerForHeader( )and registerForEvent( ) registerForFloat( ), and registerForShort( ).Until there is registration, no data is passed. The methods forregistration for messaging are generally not overwritten, but the baseclass method is used directly, as in the example. These methodsgenerally provide all the essential functionality needed by the port.Methods are also provided for message buffer management: getFloatStruct(), getEventStruct( ), getZeroCopyFloatStruct( ), anddestroyZeroCopyFloatStruct( ), which allow the extended component tospecially manage memory for incoming packets. Typically, the methods formessage buffer management are used directly as inherited from the baseclass. However, these may be overloaded by the component writer forspecial customized buffer management. There are methods for the receiptof messages: acceptHeaderPacket( ), acceptFloatPacket( ),acceptShortPacket( ), acceptEventPacket( ). These methods must beoverloaded by the component, and generally are the entry point for thesignal processing algorithm software. These methods are invoked by theinput port upon receipt of the packet message at the framework interfaceof the input port, providing of course the appropriate registrationmethod has previously been invoked. These methods execute the signalprocessing, typically by making a method invocation of a method in someobject, often the transform object, that will actually perform thesignal processing. In the example, the acceptFloatPacket( ) methods ofTmpDataInput invokes the acceptDataPacket( ) method of the object ofclass TmpTransform. In the example, the acceptEventPacket( ) methodinvokes the acceptEventPacket( ) method of the controller, the TmpCntlclass, to set the attribute dataEnable of the controller. For additionalutility there are miscellaneous methods used by a component developerand the Framework Manager. These include setPortName( ) getPortName( ),which allows the components to set and retrieve an identificationcharacter string for the input port. The method getExpectedInputType( )allows an application to query the inPort to see what type of data is itexpecting to receive. Likewise the method, setExpectedInputType( )establishes that. The method getBytesPerSecond( ) allows objects withinthe component to obtain the amount of data passing through the inputport. These miscellaneous methods are generally not overloaded by thecomponents developer as they provide all the required functionalitydirectly from the base classes.

The above methods are common to all the signal processing and are usedby the component input port to launch the signal-processing within thecomponent. It will be appreciated that the few data types accepted andprocessed by the inPort base class accommodates all of the input signalsthat one would expect to receive in a signal processing system; they arereused no matter what type of specialized signal processing is providedby the transform within the component.

The input port also interfaces with the framework to actually receivethe communication of data or events from the output port of some othercomponent. This framework side of the interface has anacceptFloatPacket( ), acceptShortPacket( ), and acceptEventPacket( )method. In one embodiment, these exterior methods are implemented asmethods of interface classes in IDL, the interface definition languagefor CORBA.

Additionally, this framework side interface has a method calledaddConnection( ) point which allows for connection-based communicationmechanisms that establish a virtual connection from output port to inputport along with an associated protocol handshake, as part of thecommunication link establishment sequence, when required by thecommunications mechanism.

Component Control

With respect to the component base class, the purpose of the componentbase class and the component, which is extended from the component baseclass, is to control the operation of the component itself. In thepresent example, the class TmpCntl extends the base class Component.Generally, this class is a singleton object, that is only one percomponent. The functionality of the extended component includes theinitialization of the component, the setting up of the input ports, theoutput ports, the parameters and connection to the Processor Manager.The extended component class initializes the number of input and outputports needed and provides the start, stop, and shutdown mechanisms forthe component.

A number of methods must be defined in the class extended from thecomponent base class. These include the constructor and destructor, inthis example TmpCntl( ) and .about.TmpCntl( ). The component base classhas methods to manage any data input/output activity. The start( )method of the Component base class is overloaded in start( ) of TmpCntlclass. This method is invoked when the component may emit data andinitiate signal processing. Similarly, stop( ) is the method that isinvoked by the framework to indicate the component is to stop emittingdata. The requestOutputPort( ) method performs any necessary processingwhen the framework requests the creation of an additional output port.The component may either extend this, in that case adding thefunctionality or creating the new output port, or as in the exampleTmpCntl, may not overload this method if the component writer desiresnot to support this functionality in the component. The shutdown( )method must be overloaded to clean up or stop any threads from beingstarted and to remove any data structures created by new( ) or othersimilar memory allocation mechanism.

The method for getName( ) must be overloaded by the particularcomponent, as is done in the example TmpCntl. This method returns aunique identifying string for the component. The methods to update thecomponents statistics called update component statistics is alsooverloaded and methods to update components called parameters is calledupdate parameters.

In the component base class there are non-virtual methods that are usedun-extended from the component base class, as they provide to all thenecessary functionality. These methods of the component base classinclude initialize( ), which is used to indicate any initialization iscomplete. The method getComponentID allows objects within the componentaccess to the unique identifier for the instance of the component. Amethod sendMessage( ) is provided that is independent of operatingsystem, compute platform, or available input/output devices to indicateerror conditions. This method sendMessage( ) is used to send errormessages to the Processor Manager, the Framework Manager and all whohave registered to receive these error messages. Methods are provided tomanage the input ports and output ports typically part of a component,and have associations with the extended component class. getInputPorts(), getOutputPorts( ) return lists of the current input ports and outputports of that particular component. The methods addInputPort( ),addOutputPort( ), deleteInputPort( ) and deleteOutputPort( ) modifythese lists of current input and output ports for the component. Thecomponent base class has a method getParameterSet( ) which allowsobjects in the component to have access to the parameter set class thatcontrols component behavior. See below for a detailed explanation of theparameter set object.

Components have statistics allowing visibility at run-time to theprocessing operation of the component. Statistics are actually parametersets that are output only, that is they do not permit changes to valuesexternal to the component. They provide a convenient mechanism for thecomponent to present internal data to outside a component due to theirself describing mechanism. Statistics are maintained within thecomponent and may be queried and may be emitted periodically. Thecomponent base class provides methods to manage the statistics. Thestatistics typically represent information about the processing rate oreffectiveness, such as samples processed per unit time, number of newsignals detected, or other information germane to development andoperation of signal processing systems. These methods includegetComponentStatistics( ) providing access to the parameterSet objectwhich is serving as the statistics object. During initialization,objects within the component may invoke the methodaddComponentStatistic( ) for each desired statistic, likewise duringdestruction the component invokes deleteComponentStatistic( ). Themethod sendComponentStatistics( ) sends the statistics to all objectsthat have registered. The component extends the component base classmethod updateComponentStatistics( ) to compute any new statisticsvalues. Typically this is invoked just prior to sendComponentStatistics(). A set of utility methods to manage the update timing of statistics isprovided. The methods setStatisticsRefreshInterval( ) andgetStatisticsRefreshInterval( ) establish and query the time betweenupdates. The method statisticsRefreshRequired( ) is provided that thecomponent invokes to test if the statistics refresh interval has a gainexpired. In typical operation, if this method returns true, theupdateComponentStatistics( ) and sendComponentStatistics( ) methods areinvoked. Additionally, a convenience method,getLastStatisticsUpdateTime( ) is provided that permits objects withinthe component to ascertain when the last statistics update wasperformed. These methods offer a multiplicity of options for thecomponent developer to manage statistics generation and reporting.

The component base class has as an attribute, a ComponentPlotSet object,which is a list of ComponentPlot objects. These plot classes will bedescribed below. The component base class has an access method to thecomponentPlotSet, plots( ).

The component interfaces with the framework to receive methodinvocations to control the component, and to produce informationrequested of the component by the framework or outside applications. Inone embodiment, these exterior methods are implemented as methods ofinterface classes in IDL, the interface definition language for CORBA.These exterior interfaces for the component include getting componentattributes: getComponentID( ), getComponentName( ), and getHostName( ).The framework side interface to the component has the following methods:start( ) which starts the component operation, eventually invokingstart( ) on the component, in the present example on TmpCntl; stop( )which the framework uses to command the component to stop its operation,eventually invoking stop( ) on the component, in the present example,TmpCntl; shutdown( ) which the framework uses to command the componentto prepare for shutdown and delete threads and to delete datastructures, eventually invoking shutdown( ) on the component, in thepresent example on TmpCntl. Message logging is managed byenableMessageLogging( ) and disableMessageLogging( ) which are used todirectly connect the sendMessage( ) from within the component to theframeworkManager and any other applications that have registered forerror reporting. Graphical plotting applications outside of thecomponent may invoke the getPlots( ) method, returning a list of plotsthe component has created and registered.

This framework interface to the component has access methods to theinput and output ports. These access methods getInputPort( ) andgetOutputPort( ) return the port, if one exists, given a name string ofcharacters. Lists of input ports and output ports are available usingthe getInputPorts( ) and getOutputPorts( ) methods.

The parameters that control the behavior of the component are availableto the framework and outside applications via the getParameter( )method, and are settable via the setParameter( ) method. The definitionsof the parameters are available via the getParameterDefs( ) method.

The statistics available within the component are available representedas parameters via getCurrentStatistics( ) and the definitions areavailable via the getstatisticsDefinitions( ) methods. A callback isestablished to request periodic statistics updated by the component byinvoking establishStatisticsCallback( ), and may be canceled by invokingcancelStatisticsCallback( ).

The requestOutputPort( ) method allows the framework to request thecomponent to create a new output port on demand, and calls therequestOutputPort( ) method of the component, if overloaded. ThereleaseOutputPort( ) method likewise will request the destruction of anynewly created output port that was created this way.

Component Outputs

With respect to the output port interface, the OutPort base classprovides two required functions inside the component. First, is theemission of the signal or event data that was just processed by thecomponent. Again, this is in the form of float data or short data with aheader or event data, for instance, when the signal-processing componentis providing such detection and the detection actually occurs from thesignal data that is fed into it. The second functionality of the outputport is to manage parameters that are used to control the transformassociated with the output port. In the example, the TmpOutput classinherits from the OutPort class. The parameters of this output portcontrol the behavior of the TmpTransform class, which is associated withthe TmpOutput class. The constructor OutPort( ) and destructor.about.OutPort( ) are extended by the component developer to become theparticular inPort that is used for the particular component, In theexample these extended methods are TmpOutput( ) and .about.TmpOutput( ).The OutPort base class has other methods that typically are used withoutextension, including getComponent( ) which allows the application to getthe reference of the component that contains the outport, andgetPortName( ) and setPortName( ), a string used to identify the outportto the Framework Manager. The send( ) method is the method invoked bythe component or transform within the component to actually send thedata from the output port of one component to the input port of anothercomponent.

There are methods to manage the output port parameters. These parametercontrols the behavior of the transform associated with the outPortclass. This includes the method updateParameters( ), which is a methodof the extended outPort class, such as TmpOutput in the present example.This method is invoked when parameter values are changed, and containsthe specific behavior programmed by the component developer to occurupon changes in parameters of the OutPort. The methods of the base classgetParameterSet( ), and setParameterSet( ), are used by the component ortransform to define the set of parameters typically during constructionof the OutPort object, and to get the current parameter set object.

The output port also has an interface to the framework to actuallycommunicate data or events to other components, and to manage thiscommunication, plus for the management and control of parameters of thetransforms associated with the output ports. In one embodiment, theseexterior methods are implemented as methods of interface classes in IDL,the interface definition language for CORBA. The interface includesmethods to get the port name get_portName( ), get the emitted data type,get_dataType( ), and get the list of inputPorts connected to the outputport, getinputConnections. The parameters of the output port areobtained from outside the component using the getParameters( ) method.The definitions of the parameters of the output port are obtained fromoutside the component using the getParameterDefs( ) method. Outsideapplications or the Framework Manager change values of these parametersusing the setParameters( ) method. The method connectInput( ) is themechanism the Framework Manager uses to establish the connections fromthe output port to the input port of the other component. ThedisconnectInput( ) method removes the connection established by theconnectInput( ) method.

Parameters

The parameters are now described. Parameters are self describingentities that control the behavior a component or of a transformassociated with an output port. Parameters are consistent over the lifeof the component that is, they exist in the beginning of the componentuntil the component destructor is called. Parameters always have thedefault values, and the values of parameters can be modified after theyare set. Again, parameters are externally observable, that is,observable by the Framework Manager and outside applications, as well asbeing observable internally to the component.

The parameters are managed by the ParametersSet class, which is acontainer class, which can store individual parameters as parameterrecords. The ParameterRcd objects are stored in the parameterSet. EachParameterRcd describes the single parameter that controls the signalprocessing behavior of the transform or of the component. This behavioris controlled at runtime. By using this parameter interface, there is acommon mechanism for all components in order to modify the behavior ofthe component regardless of the detailed parameters. The ParameterSetclass is not extended but is used unchanged. It is used in its entiretyto provide all its capabilities simply by changing the values atruntime. Each individual ParameterRcd object can store one of threetypes of data, integer, double or a string. Each ParameterRcd object hasthe following five entities: the current value, the default value thatexists when the component is first constructed, the minimum acceptablevalue, the maximum acceptable value, and a list of acceptable valueswhere acceptable values can be enumerated, instead of being controlledby a minimum and maximum. If an attempt is made to set the value of aparameter outside of these minimum and maximum limits, an exceptionautomatically occurs and the value is not set within the component.

The following methods are provided to control objects of classParameterSet, which is the container of multiple parameter records.These methods include methods used for accessing the parameters,getIntParameter( ), getStringParameter( ), getDoubleParameter( ),getName( ). The method getIntParameter( ) obtains the value element of aParameterRcd of a specified name in integer format. The methodgetStringParameter( ) obtains the value element of a ParameterRcd of aspecified name in string format. The method getDoubleParameter( )obtains the value element of a ParameterRcd of a specified name indouble precision floating point format. The method getName( ) returnsthe name of the ParameterSet established typically by the constructor ofthe component. There are complementary methods to set the parameters:setName( ) establishes the name of the parameterSet, setParameter( )establishes the value of the ParameterRcd identified by the namespecified. A convenience method is provided for the component or otherobjects within the component, to fetch parameters modified by theframework or other outside application, fetchModifiedValue( ) andfetchNextModifiedValue( ).

There are methods provided on the ParameterSet used to add, update anddelete parameters. These are typically used during the construction ordestruction of the component. The addParameter( ) method accepts newparameters by name and default value, and is used by components tocreate unique parameters for a particular signal processing application.The method addEnumeration( ) accepts enumerated values such as “A”, “B”,“C”, or “D” to be added to a specified parameter. The methodremoveParameter( ) allows for the parameter to be removed. This istypically used during the destructor. There are methods used to resetparameters to default values, resetAll( ) and reset( ) which take thename of the parameter. This allows the component to return to thedefault value rather than a currently set value, a value that was set bythe Framework Manager. The updateParameterSet( ) method tests each valueof each parameter to ensure it is within bounds prior to setting thevalue of the parameter.

Each ParameterSet is composed of ParameterRcd objects. A ParameterRcdclass has a number of methods that are used to manipulate the parameterrecord itself. The constructor for the ParameterRcd object creates theobject. The method getDataType( ) retrieves the data type of aparticular ParameterRcd object. Additional methods on the ParameterRcdclass include getAcceptableValues( ) which returns a vector ofacceptable values set during the construction and creation of theParameterRcd. The getName( ) methods returns the name of the parameter,getDoubleParameter( ) returns the value of the parameter as a doubleprecision floating point number, getStringParameter( ) returns the valueof the parameter as a character string, and getIntParameter( ) returnsthe value of the parameter as an integer. The method getDefaultValue( )returns the default value of the particular parameter record. The methodSetParameters( ) attempts to set the value of the parameter, firstchecking the minimum and maximum acceptable values, or the permittedenumerated values. The methods getMaxValue( ) and getMinValue( ) returnsthe maximum and minimum acceptable values of the parameter, which wasset when the ParameterRcd was constructed. The method getValue( ) getsthe actual and current value of that ParameterRcd.

The component interfaces with the framework to set and get theparameters of components or output ports. In one embodiment, theseexterior methods are implemented as methods of interface classes in IDL,the interface definition language for CORBA. These exterior interfacesfor the parameters interface to the framework is through the componentbase class. The parameters that control the behavior of the componentare available to the framework and outside applications via thegetParameter( ) method, and are settable via the setParameter( ) method.The definitions of the parameters are available via thegetParameterDefs( ) method. Upon a setParameter( ) invocation, theparameter is checked and the updateParameters( ) method of the extendedcomponent base class is invoked. In the present example that method isthe updateParameters( ) method of TmpCntl. The component updates anyattributes and performs any changes in behavior as the parametersdictate.

Transform

What is now described is the transform base class. The transform baseclass is extended by the component developer. The transform is oneinstance of the signal processing performed by the component. Thetransform class is where the signal processing work gets done inside thecomponent. In the present example, each object that will perform thesignal processing is of class TmpTransform, which inherits fromTransformBaseClass. This encapsulates the signal processing involvedinside the component. At least one of the transform base class methodsacceptDataPacket( ) and acceptEventPacket( ), must be overloaded by thecomponent developer, as is done in the present example TmpTransformclass, having the acceptDataPacket( ) method which is where the signalprocessing code goes. When data arrives at the component, it arrives inthe input port, on the framework side of the interface, invokingacceptFloatPacket( ), for example if the data type is floating pointdata representing signal samples. The component extended inport, in theexample TmpDataInput, calls the acceptFloatPacket( ) method. This methodtypically calls the acceptDataPacket( ) of the extended transformobject, in the example TmpTransform. The acceptDataPacket( ) of theextended transform object performs the signal processing work. When thesignal processing work is completed for that packet, the transformobject invokes the send( ) method on the output port. The transform baseclass has minimal functionality, but is extended and is where the signalprocessing work is inserted by the component developer. All the otherrequired interfaces and infrastructure support are provided by theextended inPort class which, again, is providing input data in properformat as it arrives.

Plots

With respect to the Component plot interface, it should be firstmentioned that traditional software development tools do not provideuseful representation of vectors or arrays of sampled data such that asignal processing engineer can quickly visualize the internalfunctioning, or perhaps more correctly, the malfunctioning of thecomponent software during development. The plot class is an interface isto permit the visualization of the data in a graphical format.Specifically for signal processing, this is the software analog of anoscilloscope probe.

The plot capability includes the ComponentsPlot set class and aComponentPlot. The ComponentPlotSet is a container class ofComponentsPlots which will be described first. The Component base classhas one ComponentPlotSet. The ComponentPlot provides updated graphicalplot of data within the component used for signal processing debuggingand diagnostics. These plots can be viewed with an external application.The ComponentPlot class is extended to create a plot class specificallyfor that component. In the example it is class TmpPlot. Each extendedComponentPlot has a parameter set to define and control the behavior ofthe plot itself. This interface is similar to the parameter set of thecomponent, and in fact, uses the same class parameterSet. The extendedComponentPlot has a method for getting the plot name: getPlotName( ).The extended ComponentPlot class also has methods to manage the plotsupdates: selectPlot( ) which is called when the external plottingapplication requests the plot, and refreshPlot( ) which is calledinternally by the component and provides the rendering of the plot. TheselectPlot( ) and refreshPlot( ) methods are completed by the componentdeveloper to render and populate the plot using plot tool interfacemethods, which will be described later. The ComponentPlot base class hasa method to obtain the parameters of the plot: getParameters( ), and amethod to obtain the plot tool interface that is the reference of theexternal application via getPlotTool. The ComponentPlot base classmethod refreshRequired( ) which tests whether a timer has expired andwhether it is time to render the plot and the method setRefreshInterval() which establishes how often the plot should be plotted.

The ComponentPlotSet class is the container of ComponentPlot objects.The methods on the ComponentPlotSet provide access methods by name:getPlot( ), getParameters( ), refreshRequired( ) refreshPlot( ) andselectPlot( ) and cancelPlot( ) for an entire container of plots. Theseare similar in functionality to the similarly named methods on theindividual ComponentPlot class. The ComponentPlotSet class also hasmethods for adding a ComponentPlot object once created: AddCPlot( ) andfor removing a ComponentPlot object: RemoveCPlot( ).

The component plot interface also interfaces to an external graphicsplotting application for the framework. This interface is typically usedby the selectPlot( ) and refreshPlot( ) methods on the extendedComponentPlot object, in the present example, an object of classTmpPlot, to render plots on the external graphics plotting applicationupon request of the external application. From within the component,this interface is constant. This interface has a method to add andinitialize a plot and a method to remove a plot: addPlot( ) andremovePlot( ). A method setPlotTool( ) is provided to specify whichinstance of an external graphical plotting application is to be used,given a handle, the format of which is a function of the underlyingcommunications mechanism used in the embodiment of the framework. Amethod is provided to add and initialize a text panel on the externalplotting application, addTextPanel( ), to clear text from the renderedpanel, clearText( ), and a method to write text to the panel, writeText(). Methods are provided to plot a vector of signal data as a function ofindex, plotfx( ) and to plot a pair of vectors of signal data, onevector being the abscissa, and one being the ordinate of the point to berendered, plotxy( ). As described, the external graphics plottingapplication interfaces with components to receive commands to renderplot information graphically. In the preferred embodiment, thesecommands are implemented as methods of interface classes in IDL. Thesemethods have the same nomenclature and arguments as the methods justdescribed.

The component interfaces with the framework to manage the plottingfunctionality. In one embodiment, these exterior methods are implementedas methods of interface classes in IDL. These exterior interfaces forthe plots interface to the framework is through the component baseclass. The plot interface on the exterior of the component consists of amethod which an external graphics plotting application can invoke toquery each component for all the possible plots that it can provide,getAvailablePlots( ). An external graphics plotting application can alsoquery the component for the parameters that may control the plots,parametersForPlot( ). When an external graphics plotting applicationneeds to commence rendering the plot, it invokes the selectPlot( )method on the exterior interface, which invokes the selectPlot( ) andrefreshPlot( ) methods on the extended ComponentPlot object, in theexample, an object of class TmpPlot. These methods use the renderingmethods described above, such as plot( ), to render plots on theexternal graphics plotting application. When an external graphicsplotting application no longer requires the rendering of signal data, itmay invoke the cancelPlot( ) method which indicates to stop renderingthe particular plot.

Framework Manager

Having described the base classes and their application to an examplecomponent, attention is now turned to the Framework Manager.

It will be appreciated that the entire functionality of the FrameworkManager is captured by the interface, which will be described.

The Framework Manager is the root object for the system. It is asingleton in that there is one and only one in each system using thiscomponent and framework architecture. The responsibility of theFramework Manager is to keep track of all processors and components. Itallows an outside application or applications to identify and locate theprocessors and components executing on those processors. The FrameworkManager's principal role is to manage and deploy the Plan, the Planbeing the location of the components on the computers, componentinterconnection, and the parameters that control component behavior.These three things, in combination, define the system itself, includingits operation and its ultimate function as a signal processor.

Framework Manager has a method for the Processor Manager to register,registerProcessor( ) used when the each Processor Manager startsoperating, used to indicate to the Framework Manager that processor isavailable for use in the system. A method is provided for any outsideapplication program to get the list of Processor Managers currentlyregistered, getProcessors( ). The Framework Manager has a methods toobtain a list of which components are currently executing on eachprocessor, getProcessorDetails( ). A similar method is available thatidentifies the processor executing a particular instance of a component,getProcessorForComponent( ).

A number of methods of the Framework Manager provide control and statusinformation relative to the component itself: a method to register acomponent which a Processors Manager invokes when the component has beenloaded and is ready to run, registerComponent( ), and similarlyunregisterComponent( ) which is called by the Processor Manager when thecomponent has shut down; and a method to get the list of componentsmatching certain text strings called getComponents( ). Likewise, asimilar method findComponent( ) returns a list of components matchingcertain names and parameter name, value pairs.

There are a number of methods the Framework Manager provides that areused for the deployment of components. They are used by an outsideapplication in preparation of a Plan. The first is allocateComponenID( )which ensures a unique component identity on the existing system. TheenterPlan( ) method accepts a Plan as a formatted data structure to beentered and deployed, and connections established and parameters set onthe particular components identified in the Plan. A similar methodenterPlanAsText( ) is also available that accepts the Plan in a humanunderstandable text format. Similarly, enterPlanAsFile( ) allows a filename to be specified and the Plan read from the specified file. Onceentered into the Framework Manager, the Plan may be started. A methodcalled startPlan( ) starts all the components in a Plan with thespecified name. A method stopPlan( ) stops all the components in a Planwith the specified name. The method removePlan( ) shuts down, invokesthe shutdown( ) method on each component, and unloads all thecomponents, given the specified Plan name. The method listPlan( )provides a list of all Plans that have been deployed or entered into theFramework Manager. The placeComponentMethod( ), which allows anindividual component to be placed in addition to that of the Plan. TheremoveComponentMethod( ) which removes an individual component. ThemakeConnection( ) method which connects between the output port of onecomponent and the input port of another component. This can be doneindividually in addition to those identified in a Plan. Likewise,removeConnection( ) method removes an individual connection.

It will be appreciated that each of these methods will be used toprovide various configuration and reconfiguration at runtime of thesystem. In addition, the Framework Manager has an extensible interfaceto a configuration manager object, not included in this system, whichallows an external algorithm to be used for automated deployment, andconnections of components, in some optimized manner.

In summary, the Framework Manager allows one to configure andreconfigure the entire signal processing system to be able to add andsubtract functionality and reconfigure the entire system on the fly,thus to be able to provide differing signal processing functions withinthe same equipment suite.

In the configuration process the Plan is read by the Framework Managerin one of its many forms as described above. The components areactivated on each of the processors specified each of the components areconstructed and are then connected with their initial parameter settingare set. When all that is completed, then each of the components havetheir start( ) method invoked, which then starts the processing andemitting of data out of the component.

To reconfigure, in the simplest example, a pair of components isdisconnected by the Framework Manager, the first component is shut down,another third component deployed, and this third component is connectedby connecting the output port of this third component to the input portof the second component. The third component is started and the systemnow operates performing a different functionality on the same equipment.

Processor Manager

As another integral component to the signal processing system asdescribed above, what is now described is the Processor Manager.

The Processor Manager program resides on each processor within thesystem. The Processor Manager program is automatically started on eachprocessor when the processor boots up. The Processor Manager is anextension of the Framework Manager projected onto each processor. TheProcessor Manager loads and starts components at the direction of theFramework Manager, and reports the current processor status andutilization to the Framework Manager. The Processor Manager methodsinclude the method ping( ), which by invoking, the Framework Manager candetermined whether the Processor Manager is currently operating; and theregisterComponent( ) method in which a component executing on theprocessor invokes upon its construction to inform the Processor Managerthat the component is ready to process. The enableMessageLogging( ) andthe disableMessageLogging( ) methods are used by the Framework Managerto tell the Processor Manager to forward any error messages created inthe components using the Component base class method sendMessage( ) fromthe component to the Processor Manager, to the Framework Manager, andwhich then may be passed to an external application to display the errormessages. The listLoadedComponents( ) method provides a list ofcomponents currently loaded on the processor. The loadComponent( )method is used by the Framework Manager to request a particularcomponent be loaded on the processor managed by the Processor Manager.This is typically used during the initial deployment and configurationby the Framework Manager. The removeComponent( ) method is used by theFramework Manager to shutdown and unload the component from theprocessor managed by the Processor Manager. In addition, the ProcessorManager provides usage metrics, which may be used for optimization oranalysis of component deployment: the fetchMetrics method which returnsdata about the processor utilization and memory utilization.

While the subject system has been described in terms of components, baseclasses, a Framework Manager, and a Processor Manager, when it runs aparticular signal processing task, it may involve the communication withoutside application programs. Note that the outside application programscan also be used for diagnosing the system. Outside application programsare illustrated at 50 in FIG. 2 which function as follows:

The outside application program interfaces to the parameter set,parameter record and the interface of the components changing individualparameters, which change the behavior of the components at runtime.Additionally, the outside application program can contain a plottingapplication used by the component plot class. This is referred to as theplot object.

The outside application can also change parameters of the components.The outside application can graphically render the plot output asprovided by the components and the component plots interface 40. Bychanging the parameters on the component or the parameters of the outputport, the behavior of the transform and component can be changed atruntime and the effect of those changes can be observed on thosecomponent plots which are returned to the outside application program.

Layered Architecture

Referring now to FIG. 6, the layered architecture for the presentinvention is shown. By a layered architecture is meant that objects ormodules of the system software are organized into sets referred to aslayers. When a module is part of one layer it can use any other modulein that layer directly. However, when a module in one layer must use thecapabilities in another layer it can only do so according to the strictinterface definition at the layer-to-layer boundary. Layers are used toreduce complexity by restricting relationships between modules therebyproviding independence between different parts of the system. The goalis to increase reusability and maintainability in software systems. Forexample, by layering the operating system interface, one ensures that achange in operating system does not affect the entire software system.

As illustrated in FIG. 6, particular computer hardware 88 actuallyexecutes the computer code to run the signal processing application.Higher level software does not interact directly with the computerhardware, instead it interfaces through the specific Operating System86. Example operating systems which have been used for implementing thissystem include Microsoft Windows NT, VxWorks, and LINUX. Since thesevarious operating systems and others all have somewhat differentinterfaces, the translation is isolated within the Operating SystemApplication-Programming Interface, or OSAPI, layer 84 composed of theOSAPI class.

The OSAPI provides platform-independent and operating-system-independentmethods to access the underlying operating system capabilities. Thus theOSAPI layer is a translation from the native operating system to acommon interface used by the components regardless of the nativeoperating system or native hardware platform.

These include but are not limited to methods to change specificdirectory or path, chdir( ) or fixPath( ); methods to start a task orperform a system call, spawn( ) and system( ); methods for environmentinitialization or host management, startup( ), getHostName( ), hostType(); and methods for swapping bytes and determining the so-called Endiantype of the platform, such as littleEndian( ), swap2ByteData( ),swap4ByteData( ), swap8ByteData( ) which provide platform independentoperation. Methods to handle time functions using seconds ormicroseconds such as getHighResTime( ), geTimeofDay( ), timeToText( ),sleep( ), usleep( ) may be used; and other methods to control processinginclude, taskLock( ), taskUnlock( ), contextSwitch( ) and to move data,fastestCopy( ). These are all independent of the underlying actualoperating system and allow the same source code to be used in multipleprocessor environments and operating system environments. Endiandescribes the ordering used natively by the machine in a multi-byteword. For example, a four byte integer in little endian representationhas the least significant byte placed first in memory and the mostsignificant byte placed fourth in memory. In big endian representation,the first byte in memory is the most significant byte; the third byte orthe fourth byte in memory is the least significant byte. This endianconversion, byte swapping and endian test permits interoperation betweendifferent types of computer hardware.

A Libraries layer 82 provides a standard set of calls for signalprocessing primitives such as Fast Fourier Transform FFT( ) and FiniteImpulse Response Filter FIR( ). The interfaces to these libraries isconstant regardless of the actual computer type being used to performthe computations. In one embodiment the interface to the components isprovided by the industry-standard Vector Signal and Image ProcessingLibrary (VSIPL). Most hardware vendors provide VSIPL libraries that areoptimized for their hardware platform.

The CORBA layer 96 provides default method for remote object methodinvocation in one embodiment. CORBA stands for the industry standardCommon Object Request Broker Architecture and it is implemented by anoff-the-shelf product. This selection is in keeping with the underlyingobject-oriented architecture of the system, but can be changed and sohas been isolated in its own layer. Other communication means includesockets, which are supported by the target operating systems, and thenative communications protocols of the switched fabric interconnects arealso available within the distributed framework.

A Distributed Framework layer 94 consists of the Framework Manager,Processor Managers and other objects and services which provide theinfrastructure for operating the components in a system.

The Component Base Classes layer 92 provides most of the genericcapabilities needed by all components in the system. These base classesare described in detail above. This layer facilitates rapid developmentof components from direct reuse of much common software code. Byproviding the interface between the Specific Application Components 80and the interface from the Components 80 and the Distributed Framework94, it relieves the software component developer from the burden ofcomplying with these interfaces.

Specific interfaces are also defined between the Component Base Classes,the Distributed Framework, CORBA, and the Outside Applications 90 whichcontrol the system and receive the processing results. Examples includethe plot interfaces, parameters interface, and statistics interface fromthe component base classes, and the Framework Manager and processormanager interfaces as described above.

A program listing for the illustrated embodiment is provided in theAppendix hereto.

Having now described a few embodiments of the invention, and somemodifications and variations thereto, it should be apparent to thoseskilled in the art that the foregoing is merely illustrative and notlimiting, having been presented by the way of example only. Numerousmodifications and other embodiments are within the scope of one ofordinary skill in the art and are contemplated as falling within thescope of the invention as limited only by the appended claims andequivalents thereto.

1. A layered architecture system, comprising: at least one module,operating on a first layer of a plurality of layers, configured tointeract directly with any other module on the first layer; and aninterface layer, adapted between the first layer and a second layer ofthe plurality of layers at a layer boundary, configured to provide acommon interface between the at least one module and the second layer inaccordance to an interface definition at the layer boundary.
 2. Thelayered architecture system of claim 1, wherein the plurality of layerscomprises an operating system layer acting as an interface between acomputer hardware layer and a distributed framework layer.
 3. Thelayered architecture system of claim 2, wherein modules corresponding tothe distributed framework layer interact with modules corresponding tothe computer hardware layer via an operating system applicationprogramming interface.
 4. The layered architecture system of claim 1,wherein the plurality of layers comprises a distributed framework layerthat includes a framework manager and at least one processor managerconfigured to operate on the distributed framework layer.
 5. The layeredarchitecture system of claim 1, wherein the plurality of layerscomprises an application component layer including a plurality ofcomponents configured to operate on the application component layer; andcomponent base classes adapted to reside on a component base classeslayer that is configured to interface between the application componentlayer and a distributed framework layer according to the interfacedefinition.
 6. The layered architecture system of claim 3, wherein theoperating system application programming interface is a commoninterface, used by a plurality of components, translated from a nativeoperating system.
 7. The layered architecture system of claim 6, whereinthe plurality of components use the operating system applicationprogramming interface layer.
 8. An article of manufacture including acomputer-readable medium having a plan stored thereon that, whenexecuted by a computing device, cause the computing device to performoperations of the plan comprising: configuring a plurality of componentsthat provide at least one function using a processor; communicativelyconnecting the plurality of components and the processor; passinginformation identifying at least one of the plurality of components toassociated processor managers of respective ones of a plurality ofcomputers, wherein the associated processor managers are configured todownload the at least one of the plurality of components to therespective ones of the computers; identifying communicative connectionsbetween individual components of the plurality of components on a datacommunication fabric; establishing the identified communicativeconnections between the individual components of the plurality ofcomponents on the data communication fabric; and specifying a pluralityof functions executed by a local distributed processor operating theindividual components of the plurality of components.
 9. The article ofmanufacture of claim 8, wherein the plan is a preformatted filecomprising a configuration of the plurality of components to be used tosolve a particular signal processing problem.
 10. The article ofmanufacture of claim 8, wherein the plan defines initial parametervalues of the plurality of components.
 11. The article of manufacture ofclaim 8, wherein the plan defines system functionality and capability atruntime.
 12. The article of manufacture of claim 8, wherein the plandefines interconnection communication mechanisms.
 13. The article ofmanufacture of claim 12, wherein the interconnection communicationmechanisms comprise streams of data to be passed between the componentsto perform aggregate system processing.
 14. The article of manufactureof claim 12, wherein the interconnection communication mechanismscommunicatively connect an output port to an input port using anassociated protocol handshake.
 15. The article of manufacture of claim8, wherein the computer-readable medium has stored thereon at least onemore plan, and wherein, when the at least one more plan is executed bythe computing device, the computing device is configured to performoperations of the plan and the at least one more plan simultaneously.16. The article of manufacture of claim 15, wherein the plan and the atleast one more plan shares usage of components.
 17. The article ofmanufacture of claim 8, wherein the plan is reconfigurable when one ormore of the processors in the system fails.
 18. The article ofmanufacture of claim 8, wherein the plan defines a communication typeand the communication type is sent to ports when communications areestablished.
 19. A method of operating a layered architecture system,comprising: configuring at least one module operating on a first layerof a plurality of layers to interact directly with any other module onthe first layer; adapting an interface between the first layer and asecond layer of the plurality of layers at a layer boundary, wherein theplurality of layers comprises an application component layer including aplurality of components; and configuring the interface to control the atleast one module interacting with a different module on the second layerin accordance to an interface definition at the layer boundary.
 20. Themethod of claim 19, further comprising: configuring the plurality ofcomponents to operate on the application component layer; adaptingcomponent base classes to reside on a component base classes layer; andconfiguring the component base classes layer to interface between theapplication component layer and a distributed framework layer accordingto the interface definition.